Wow, nice work! I'll try to free some time this week to look into this

I am not sure this will be liked by all organizations, same user, same password across multiple database clusters..
Of course, nobody forces you to use it in that way..

I am personally using range logic in my Helm chart and doing all that possible.

This is not the same user across clusters, rather the ability to have one role that can access more than one database within the same postgres cluster. This is applicable when an application uses more than one database for whatever reason. An application using a primary database but reading data out of a data warehouse style DB, for instance. There is another common pattern that is used by several applications in homelab scenarios where the application uses one DB for application state persistence and another for logging. I couldn't tell you why, but this pattern is rather entrenched and unlikely to change for these projects that do it.

This retains the old usage pattern still, albeit marked as deprecated.

I agree it's not the best practice, we see the need for it in multiple issues.
You deprecated the single-database way, but I would not do that. I would still keep the single database as the primary way as this will probably be in 99% of the cases. So I would support both cases, but give an error in the status when both are configured at the same time.
I'll try to dive into your PR more next week, as this is quite a big change that I want to give some thought to.

You deprecated the single-database way, but I would not do that. I would still keep the single database as the primary way as this will probably be in 99% of the cases. So I would support both cases, but give an error in the status when both are configured at the same time.

I would argue that the deprecation is the right direction to go. A concise API makes for easier maintainability long term and allows everybody to be on the same page about how the CR should be configured. Keeping two separate ways around to do the same thing so that ???(not clear on what is gained) adds complexity.

The deprecation does not remove the ability to use, rather it marks the array pattern as the preferred pattern so that in future versions the API can be simplified.

This is not the same user across clusters, rather the ability to have one role that can access more than one database within the same postgres cluster. This is applicable when an application uses more than one database for whatever reason. An application using a primary database but reading data out of a data warehouse style DB, for instance. There is another common pattern that is used by several applications in homelab scenarios where the application uses one DB for application state persistence and another for logging. I couldn't tell you why, but this pattern is rather entrenched and unlikely to change for these projects that do it.

This retains the old usage pattern still, albeit marked as deprecated.

This means the operator should be able to authenticate to both DB instances?

This means the operator should be able to authenticate to both DB instances?

Yes? To be able to create a DB and assign permissions in a postgres instance the operator would need a sufficiently privileged account already. An account that is able to create a DB in your cluster would be able to modify that DB then also the other DB it created in that cluster. Postgres instance nomenclature and structure diagram for reference. The credential supplied to the operator can already modify everything under the cluster in this diagram.

Postgres is a little confusing in it's nomenclature. I can docker run --rm -d --name pg -e POSTGRES_PASSWORD=postgres -p 5432:5432 postgres:16-alpine and start a postgres instance (which I think you are calling a database), then within that single instance create multiple databases with my single postgres user as the db admin. This PR doesn't handle databases across multiple instances, it handles multiple databases.